< previous page page_215 next page >

Page 215
Public Const RAS_MaxPhoneNumberBuffer = 129
Public Const UNLEN = 256
Public Const UNLENBuffer = 257
Public Const PWLEN = 256
Public Const PWLENBuffer = 257
Public Const DNLEN = 15
Public Const DNLENBuffer = 16
The RASDIALPARAMS ends up looking like this:
Public Type RASDIALPARAMS
   dwSize As Long ' 4
   szEntryName As String * RAS_MaxEntryNameBuffer ' 257
   szPhoneNumber As String * RAS_MaxPhoneNumberBuffer '129
   szCallbackNumber As String * RAS_MaxPhoneNumberBuffer ' 129
   szUserName As String * UNLENBuffer ' 257
   szPassword As String * PWLENBuffer ' 257
   szDomain As String * DNLENBuffer '16
   Padding(2) As Byte
   'dwSubEntry As Long
   'dwCallbackId As Long
   '#if (WINVER >= 0x401)
   'DWORD dwSubEntry;
   'DWORD dwCallbackId;
   '#End If
End Type
What is the extra padding array at the end of the structure? This structure faces the same problem as the RASENTRYNAME structure shown in Puzzle 18. The packing is set to 4 bytes. The individual fields within the structure have no alignment problems because they all consist of arrays of single bytes, which can be located at any address. But the structure as a whole must be aligned to a 32-bit boundary. If you add up the lengths of all of the entries, you'll have 4 + 257 + 129 + 129 + 257 + 257 + 16 = 1049. The 32-bit boundary is 1052, so you need to add 3 bytes of padding.
With this structure, the function will almost work. Instead of error 632 (invalid structure size) upon startup, you'll see error 623 (invalid phone book entry) when you try to select a phone book entry. How can this be?
Consider the szEntryName field in the structure. It is a fixed-length string, which is set using the following line:
rs.szEntryName = lstEntries.Text

 
< previous page page_215 next page >